feat: Adding the JaCoCo Method Filter to the project - #147

I am adding the example of the JaCoCo report, that was triggered by fake changes.

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

Since this is intended as a common standard for projects, have you considered introducing it in the root POM instead? Publishing it as a new major version would allow each project to adopt the change explicitly and in a controlled manner, rather than applying it only within Commons.

Since this is intended as a common standard for projects, have you considered introducing it in the root POM instead? Publishing it as a new major version would allow each project to adopt the change explicitly and in a controlled manner, rather than applying it only within Commons.

@wajda @miroslavpojer

Thanks for this comment! This is the first time we face this situation with having something like a root-pom in the project. We discussed the options and I did run several tests to make sure, how would behave the change in the root-pom. I found out that it would be breaking change for the no-migrated projects and even configuration one for the migrated ones.

The output from the analysis can be seen below:

Please share your thoughts about this analysis. If we merge current working (but not ideal) solution, or we start some bigger migration with several steps. This decision is also on the @miroslavpojer to comment about the impact and our capacities.

Since this is intended as a common standard for projects, have you considered introducing it in the root POM instead? Publishing it as a new major version would allow each project to adopt the change explicitly and in a controlled manner, rather than applying it only within Commons.

@wajda @miroslavpojer

Thanks for this comment! This is the first time we face this situation with having something like a root-pom in the project. We discussed the options and I did run several tests to make sure, how would behave the change in the root-pom. I found out that it would be breaking change for the no-migrated projects and even configuration one for the migrated ones.

The output from the analysis can be seen below:

Please share your thoughts about this analysis. If we merge current working (but not ideal) solution, or we start some bigger migration with several steps. This decision is also on the @miroslavpojer to comment about the impact and our capacities.

Do not merge it. Move it into blocked in our board.
This need some time to think.
Pls, focus on other similar tasks.

Well, that LLM lies :)

First, there is no migrated/un-migrated dilemma simply because the root POM is a versioned artifact (like any other Maven artifact) that a child project references using a specific version. So, generally speaking, any braking change will stay invisible for child projects until they decided to explicitly upgrade to a newer root POM, which is always done in a controlled manner. There is no silent automatic propagation of changes downstream.

Secondly, the JMF plug-in activation can be conditional, depending on existence of the jmf-rules.txt file in the child project codebase. Doing that you can keep changes backward compatible, allowing to even smoother transition.

The cerveada version of scala-test is basically a fork of one of earlier versions of the scala-test. The only difference is this commit - cerveada/scalatest-maven-plugin@e16f1c5 for fixing references to JVM. It was done quite a while ago and I'm not sure if it's still needed. It is worth checking if things are working fine with a mainstream branch of the scalatest

Well, that LLM lies :)

First, there is no migrated/un-migrated dilemma simply because the root POM is a versioned artifact (like any other Maven artifact) that a child project references using a specific version. So, generally speaking, any braking change will stay invisible for child projects until they decided to explicitly upgrade to a newer root POM, which is always done in a controlled manner. There is no silent automatic propagation of changes downstream.

Secondly, the JMF plug-in activation can be conditional, depending on existence of the jmf-rules.txt file in the child project codebase. Doing that you can keep changes backward compatible, allowing to even smoother transition.

Yes - I agree with project migration to new root-pom.

JMF - I will check why the file is required to be present.

• There should be used internal set of filter rules or simply no rules.

The cerveada version of scala-test is basically a fork of one of earlier versions of the scala-test. The only difference is this commit - cerveada/scalatest-maven-plugin@e16f1c5 for fixing references to JVM. It was done quite a while ago and I'm not sure if it's still needed. It is worth checking if things are working fine with a mainstream branch of the scalatest

Mentioned as internal team TODO/Tech debt?

The cerveada version of scala-test is basically a fork of one of earlier versions of the scala-test. The only difference is this commit - cerveada/scalatest-maven-plugin@e16f1c5 for fixing references to JVM. It was done quite a while ago and I'm not sure if it's still needed. It is worth checking if things are working fine with a mainstream branch of the scalatest

Mentioned as internal team TODO/Tech debt?

I have no idea. It was a quick fix done a while ago in some another repo where it required no maintenance and was deemed a long-term fix, requiring no follow ups. It was you @miroslavpojer who put it to the Root POM, I don't even remember where did you pick it from 🤣 #1a1a43a4